Even though graphics hardware is constantly improving in speed, there
will always be applications that require more performance than is
available from a single pipeline. In order to overcome these limits,
it is possible to parallelize the rendering task across multiple
pipes; the image outputs of these pipes must then be assembled into
a single display output. This group of pipes is termed a hyperpipe;
the pipes involved must be physically cabled together in some way
to form a hyperpipe network. Typically a hyperpipe network uses one
of the pipes to assemble the rendered images and drive the display.
In a hyperpipe network, the rendering task may be divided by rendering
each successive frame on a different hardware pipe (temporal division);
by dividing the frame into rectangular subregions and rendering each
on a different pipe (spatial division); or by a combination of these
two techniques. Specific hardware implementations may impose limits
on how rendering may be subdivided; but in general it is possible to
use a subset of the pipes connected to a hyperpipe network if desired.
This extension provides a means for configuring and managing a group
of rendering pipes which work together to produce a single display.
Typically, a hyperpipe application will be multi threaded, with
one thread per pipe; each thread needs to create its own rendering
context. The hyperpipe extension allows these rendering threads to
communicate with the hardware.
The API calls allow an application to :
o Determine the physical configuration of a hyperpipe network.
o Configure the hyperpipe. The hyperpipe configuration used by the
application may be a subset of the physical hyperpipe network.
The rendering task may be divided in time slices (temporally divided),
in rectangular regions of a single frame (spatially divided), or both.
The hyperpipe configuration is subject to hardware constraints.
For example, on a hyperpipe network consisting of five pipes, it
would be possible to configure a rendering task in two time slices,
with each slice being rendered by two pipes; thus using four total
pipes. (The fifth pipe would not be used in the hyperpipe, and
could be used for normal non-hyperpipe rendering and display).
o Maintain state to manage the glXSwapBuffers call correctly. In
spatial subdivision, swap cannot occur until all pipes rendering
the next frame have completed; and in temporal subdivision, swap
cannot occur until the appropriate time. Swap management is
handled by the displaying pipe.
o Redirect resize parameters correctly; typically resize is handled
by the displaying pipe, and must be managed synchronously with
swap.
o Balance load among the pipes in the spatial subdivision case.
o Clean up operations when a hyperpipe application terminates
(either normally or due to error).
This extension adds to the set of conditions that must be met before
a buffer swap can take place.
FFFFUUUUNNNNCCCCTTTTIIIIOOOONNNNSSSS
The main functions are
ggggllllXXXXQQQQuuuueeeerrrryyyyHHHHyyyyppppeeeerrrrppppiiiippppeeeeNNNNeeeettttwwwwoooorrrrkkkkSSSSGGGGIIIIXXXX queries the physical hyperpipe network.
ggggllllXXXXHHHHyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooonnnnffffiiiiggggSSSSGGGGIIIIXXXX configure the hyperpipe network.
ggggllllXXXXQQQQuuuueeeerrrryyyyHHHHyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooonnnnffffiiiiggggSSSSGGGGIIIIXXXX query a particular hyperpipe configuration.
ggggllllXXXXDDDDeeeessssttttrrrrooooyyyyHHHHyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooonnnnffffiiiiggggSSSSGGGGIIIIXXXX destroy a hyperpipe configuration.
ggggllllXXXXBBBBiiiinnnnddddHHHHyyyyppppeeeerrrrppppiiiippppeeeeSSSSGGGGIIIIXXXX bind a process and rendering context to a hyperpipe
configuration.
NNNNOOOOTTTTEEEESSSS
In case of hyperpipes, it is valid to call ggggllllXXXXSSSSwwwwaaaappppBBBBuuuuffffffffeeeerrrrssss on a single buffered
visual. In addition to its usual functionality, calling ggggllllXXXXSSSSwwwwaaaappppBBBBuuuuffffffffeeeerrrrssss
on a rendering context bound to a hyperpipe, causes the hyperpipe to switch
to the next pipe.
In the case of hyperpipes, the hyperpipe id associated with a context can be
determined by calling ggggllllXXXXQQQQuuuueeeerrrryyyyCCCCoooonnnntttteeeexxxxttttIIIInnnnffffooooEEEEXXXXTTTT with an attribute of
